Cream of the Crop 20/Cream of the Crop 20 (Terry Blount) (1996).iso/program/n_b_v203.zip/A-MUST.TXT

Text File | 1996-07-04 | 6KB | 108 lines

$if 0
    ┌──────────────────────────╖                        PowerBASIC v3.20
 ┌──┤          DASoft          ╟──────────────────────┬──────────────────╖
 │  ├──────────────────────────╢    Copyright 1995    │ DATE: 1995-10-01 ╟─╖
 │  │ FILE NAME   A-MUST  .TXT ║          by          ╘════════════════─ ║ ║
 │  │                          ║  Don Schullian, Jr.                     ║ ║
 │  ╘══════════════════════════╝                                         ║ ║
 │ A license is hereby granted to the holder to use this source code in  ║ ║
 │ any program, commercial or otherwise,  without receiving the express  ║ ║
 │ permission of the copyright holder and without paying any royalties,  ║ ║
 │ as long as this code is not distributed in any compilable format.     ║ ║
 │  IE: source code files, PowerBASIC Unit files, and printed listings   ║ ║
 ╘═╤═════════════════════════════════════════════════════════════════════╝ ║
   │                ....................................                   ║
   ╘═══════════════════════════════════════════════════════════════════════╝
$endif

  This library includes one of the most important routines any data program
  will use: fTinput$. (No brag, just fact.) There are sufficient files here
  to get you up to speed with this function but what I want to discuss here
  is data input, in general.

  How you store data on the disk, how you use it in the program and how the
  users sees it do NOT have to be the same things! In fact, its usually the
  best bet to NOT use and store the data the way the users sees because the
  human brain and the CPU don't work the same way.  Dates and Times are two
  good examples of this.  Both of these can be stored in  two bytes but can
  take up to 10 bytes to display so the human can understand them. While in
  the two byte format they can be added, subtracted and stored quicker than
  when in the 10 byte format.

  Another VERY important part of a data base is the input and use of names.
  In America the average length of a name is about 17 characters. Of course
  that includes Last First Middle-Initial but leaves no room for titles and
  honorifics. Also it is quite insufficient for truly long names!  And most
  programs I have seen force the user to remember the format the name is to
  be input in! That's dangerous because users are part and parcel of an age
  old law first expounded by Mr. Murphy!  You HAVE to protect them from any
  and all possibilities of screwing up! Then you have different name styles
  in almost every country around the world, so, nothing is sacred.  To help
  relieve this problem I devised a 3 field input system that keeps the user
  honest, allows for variable length parts and lets the computer do the job
  it was designed to do.  I've gone into all this in a previous library but
  I'm going to do it all again 'cause IT IS IMPORTANT!

  Your program presents the user with 3 separate fields whose total length
  are longer than the final acceptable length of the packed data:

         Last or Family Name: Public________________________ 30 chars
    First and Middle Initial: John Q._______________________ 30 chars
                  Honorifics: Mr., III_______                15 chars

  This stops the user from entering:
    John Q. Public, III
    Mr. John Q. Public, III
    Public John Q. Mr.,III
    and a host of others
  instead of:
    Public, John Q.(Mr.,III)
  which is still kind'a confusin'!

  You take the 3 fields F1$, F2$ and F3$ and run them through
  a little routine like:  N$ = LTRIM$( F1$ ) + CHR$(0) +_
                               LTRIM$( F2$ ) + CHR$(0) +_
                               LTRIM$( F3$ )
  to pack them up into one string.

  You have only to make 2 tests on this string before accepting it:
    1) is the "packed" length of the 3 names =< 37?
    2) are all the characters in the name acceptable?
       Some languages (Greek for one) have letters that look like
       English but have different ASCii values and if an English "M"
       is inserted into a name where the Greek "M" (Me) should be the
       data will not sort correctly and the user may not be able to find
       the name afterwards.

  Now that everything is correct and within the allowable length you can
  do just about anything you want with it! Because you used CHR$(0) to
  separate the fields and you've stored the fields in the correct order
  you could UCASE the whole thing to make an index reference, store the
  whole thing to the record as one field, or use one of the name display
  functions to display any or part of the name for different uses.
  SEE: fDisplayName$

  The most important things are that you have:
    1) almost guaranteed that the incoming data is in a format that is
       correct and usable by the program
    2) there is/was sufficient room to input the separate parts of the
       name without forcing the user to compromize any one part.
       ie: Mrs. Jane A. Hyatt-Papadopoulous, PhD.  unpacked full length
           Hyatt-Papadopoulos|Jane A.|Mrs., PhD.   packed at 37 chars

  Yes, I know this seems to throw a bit more work on you, the programmer,
  but, believe me, it saves hours trying to explain to your users how
  vital it is to input the names "in the correct format" by forcing them
  to do so. It also saves hours of digging through data bases for "lost"
  records that were actually mis-filed because someone input Jane Doe
  instead of Doe, Jane. I <KNOW> this is true because I've spent those
  hours time and time again. I've even gone looking for bugs in the
  indexing routine(s) that I KNEW were good! It is also more acceptable
  to the users, I've been told, because it allows you to use names in
  several different ways for display, reports, menus, etc. which help
  the users get through their tasks easier. In short, it's just better
  than most of what I've seen over the years!

  Thanks, and happy hunting......

  d83)